🔬 The Reproducible Workflow, End to End

🔁 Git as a Reproducibility Trace

One piece of the structure deserves a word before the worked example, because it is the part most researchers skip. Git — the version-control system — records the state of your project over time. Each commit is a labelled snapshot; the history is a record of how the work actually evolved. You do not need to become a software engineer to benefit: even committing at a few milestones (“raw data inventoried,” “cleaning done,” “analysis complete”) gives you a trace that says what the project looked like at each stage, and lets you see exactly what changed between them.

Claude Code can do the Git work for you — initialise the repository, show you what changed, commit with a message — so the mechanics are not a barrier. What matters is the habit of using the history as a research record, not just a backup: a commit message like “halved upstream counts (double-counting fault, per field note); excluded contaminated D-03” turns the version history into a narrated account of your decisions. Used this way, Git is reproducibility infrastructure, not a developer's indulgence.

🔬 A Worked Reproducible Analysis

Here is the Berg River study, start to finish, with the discipline of the previous pages applied. The dataset is the same deliberately-messy archive from Lesson A.3 — downloadable below — and it has real problems planted in it: inconsistent column names, a systematic counting fault at one site, a contaminated outlier, missing values, and field notes that explain anomalies the spreadsheets don’t. Watch how the structure turns that mess into something inspectable — including one correction that, it turns out, decides the answer.

1. Put the CLAUDE.md in place. The research-habits template from B.2 goes in the project root before anything else, so every rule — don't touch data/raw/, log decisions, don't guess — is active from the first action.
2. Inspect and inventory. In plan mode, the agent reads every raw file and writes docs/data-inventory.md: the columns (and the fact that the three site files name them differently), the units, the row counts, the missing values, and the anomalies — including upstream counts that sit suspiciously close to the town’s (surprising for a site above the town), and one downstream value far higher than its neighbours. Crucially, field-notes.md explains both: the upstream counter double-counted all season, and the high downstream sample (D-03) was contaminated and should be discarded.
3. Pre-register the question. Before running the comparison, the prediction and decision rule from B.2 go into pre-registrations/ and are committed. The standard is set while there is nothing to defend.
4. Plan the analysis; you review it. Still in plan mode, the agent proposes the cleaning and analysis steps. You read the plan — this is the checkpoint — and approve it before a single file is written.
5. Clean, and log every decision. The agent writes a cleaning script to scripts/ that harmonises the column names, halves the upstream counts because the field notes record that the upstream counter double-counted all season, excludes the contaminated D-03, and handles the missing values by the pre-registered rule. Each of these choices is appended to notes/decision-log.md, dated, with its reason and its source. The raw files are never touched; the cleaned data lands in data/processed/. Watch the upstream halving in particular — it is about to decide the answer.
6. Run the analysis to a committed log. The analysis script runs the pre-registered Mann-Whitney test, prints its result to outputs/analysis_run.log (committed), and saves the figure and summary table to outputs/.
7. Record assumptions and uncertainty. The agent notes what it assumed and what remains uncertain — the small sample after exclusions, the reliance on a single field note for the upstream correction that drives the result — rather than presenting a clean result as if nothing were in doubt.
8. Commit. A Git commit snapshots the whole state, with a message that narrates the decisions.

🔎 Verifying Agentic Work

When the agent runs for an hour and makes a hundred changes you did not watch, the instinct is to inspect each one — to read every diff as it happens. That does not scale, and pretending it does is the fastest route to a false sense of safety. The volume is the problem: when so much is changing all the time, there often isn't a chance to check each change, and any carefulness that depends on watching every one will quietly fail. So the move is to take verification off the per-change axis. Don't try to catch every mistake as it happens; instead make mistakes survivable, encode what must stay true so a machine checks it, and verify the few things that actually matter. Week 9's protocols and Week 10's Princeton reliability finding (Rabanser et al., 2026) still bite — the burden is real and it grows — but the response is to automate and target verification, not to watch harder.

These layers catch different failures, and it helps to see which catches which. A wrong-direction failure — the agent confidently pursuing the wrong goal because it inferred the wrong intent, and taking you on a tangent for days — is invisible to any amount of diff-reading, because no single change is wrong; the question is wrong. That is what the pre-registration gates from B.2 are for: a closed gate stops the tangent early. A quiet-correctness failure — a dropped column, a plausible default you didn't notice — is what the automated assertions catch. And reviewing at the checkpoint (the commit boundary) rather than at every keystroke is how human review stays in the loop without becoming a full-time job. Verification scales when it is layered, not when it is heroic.

📄 Disclosure: The Reproducible Folder Is the Disclosure

Week 4 and Week 11.3 asked you to disclose your AI use. Week 11.3 also delivered the bracing finding that, against roughly 70% of journals having an AI policy, only about 0.1% of papers actually disclose (He & Bu, 2026, PNAS). Most disclosure, where it happens at all, is a vague sentence: “AI tools were used in the preparation of this work.” That sentence tells a reader almost nothing.

A reproducible project folder flips the problem. You do not need a sentence that gestures at what the AI did, because the folder shows it: the CLAUDE.md states the rules the agent worked under; the decision log records every judgement and who made it; the scripts are the method; the Git history is the sequence of events; the pre-registration proves the standard predated the result. The honest answer to “what did the AI do, and what did you decide?” is not a paragraph — it is “here is the folder.” That is what good disclosure actually looks like, and it is a higher standard than almost any journal currently asks for.